In recent years, the bandwidth demand on telecommunication networks has increased dramatically. Class protocols for 100 Gigabit/second (100 Gbps) networks have already been defined in IEEE Ethernet and in ITU-T Optical Transport Network standards. An example of such a protocol is the generic framing protocol (GFP). Four hundred Gigabits/second protocols and 1 Terabit/second (1 Tbps) protocols are expected to be defined in the near future. Although successive generations of CMOS technologies have been able to reduce the size of electronic processing elements allowing for dramatically more electronic elements (i.e. gates) per unit area, the speed of electronic processing elements in CMOS technologies has not significantly increased. Accordingly, as data rates increase, electronic processing elements must use wider internal datapaths or busses. Wider internal datapaths or busses allow for more data to be processed in parallel.
When transferring data over a network, the data is typically encapsulated as packets such as GFP frames. The frames are scrambled using a scrambler then concatenated together and transmitted. The transmitted packets are received, delineated back into packets or frames, placed on a bus W-bytes wide, and descrambled. A packet-based linecard is typically used to perform these functions.
FIG. 1 shows a typical packet-based linecard 100. On a receive side 102, serial Receive Data Rx, which is transmitted as a series of concatenated packets or frames, is converted by the SIPO (Serial In Parallel Out) 104 to parallel byte wide words of size W. For 100 Gbps streams, W is typically in the range of 32 to 64 bytes. For 1 Tbps streams, W is expected to be of the order of 512 bytes. The Frame Delineation 106 separates the Receive Data Rx into packets or frames and places them aligned to bus word boundaries of a receive packet bus 300, as shown in FIG. 3, within the Frame Delineation 106.
FIG. 2 shows an example packet of a GFP frame 200. The frame 200 has a Core Header 202 (4 bytes in length), a Type and Extension Header 204 of variable length between 4 and 64 bytes, a payload 206 of variable length, and a payload frame check sequence (FCS) (4 bytes in length) 208. The Core Header 202 includes a two byte payload length indicator (PLI) field and a two byte Core Header Error Control (cHEC) field that contains a cyclic-redundancy-check (CRC-16).
FIG. 3 shows an example frame 200 (as shown in FIG. 2) placed on a receive packet bus 300. The receive packet bus 300 comprises multiple, parallel, bus words 302 of W-byte lengths, and has at least a Start-of-Packet (SOP) Word 304, an End-of-Packet (EOP) Word 308, and potentially one or more Mid-Packet-Words 306 therebetween. The width W of the receive packet bus 300 and, accordingly the corresponding bus word 302 length W, can be any number of bytes. For 100 Gbps data rates, the receive packet bus 300 width W would likely be in the range of 32 bytes. For a 1 Tbps data rate, the receive packet bus 300 width W would likely be around 512 bytes. The Core Header 204 is aligned to the most significant byte of the SOP Word 304. Because a frame 200 is of variable length, the location of its last byte 310 can be at any position in the EOP Word 308 (as shown in FIG. 3) of the receive packet bus 300. All remaining bytes of a bus word 302, after the least significant bit of the last byte 310, are filled with null bytes.
Referring back to FIG. 1, once a frame 200 is delineated, it is sent to a Scrambler+FCS Engine 108 for de-scrambling and Payload FCS checking. Typically, the Scrambler+FCS Engine 108 is an X43+1 self-synchronous scrambler/descrambler. For GFP frames, the self-synchronous scrambler/descrambler uses a generating polynomial of G=x43+1. After higher layer protocol packet processing is performed by a Packet Processor 110, the frame 200 is written out to a FIFO 112.
FIG. 4 shows a logical bit-serial representation of a typical X43+1 self-synchronous scrambler/descrambler 400 (scrambler) defined in ITU-T G.7041. The scrambler 400 scrambles and descrambles bits in a data stream by using previously scrambled or descrambled bits, respectively. This helps ensure rich transition densities on serial optical transmission streams. As discussed below, the scrambler 400 is only a component of a larger electronic circuit for performing the scrambling and descrambling function in the packet-based linecard.
The scrambler 400 has an input 402, an XOR module 404, an output 406, and a series of 43 delay modules 408. In operation, the representative scrambler 400 receives data D(t) comprising a series of bits at its input 402. Each bit is exclusive-ORed by the XOR module 404 with a second bit from a 43rd delay module 408. The result of the exclusive-OR is sent to the output 406 and also saved to a 1st delay module 408. For each bit of data D(t) exclusive-ORed by the representative scrambler 400, the results stored in the delay modules 408 are advanced, one-by-one beginning at the 1st delay module 408 and proceeding to the 43rd delay module 408. The same scrambler 400, with the same number of delay modules 408 must be used on both the transmit side 114 and the receive side 102, as defined in FIG. 1.
On the transmit side 114, a bit stream is read from the FIFO 112 by the Packet Processor 110. The Packet Processor 110 performs higher layer packet processing on the bit stream and adds a Core Header 202, and optionally, a Type and Extension Header 204, thereto to create a packet or frame 200. At the output of the Packet Processor 110, the frame 200 is placed on a transmit packet bus. A transmit packet bus is essentially the same as the receive packet bus 300 as shown in FIG. 3. Payload FCS 208 is added and the frame 200 is scrambled by the Scrambler+FCS Engine 108 in a manner similar to that described above. Frames 200 are then concatenated together by the Frame Concatenation 116 and serialized for transmission by the PISO (Parallel In Serial Out) 118.
During operation, the scrambler 400 neither scrambles nor descrambles, nor uses for scrambling/descrambling, bits in the Core Header 202. Since the N NULL bytes beyond the payload FCS bytes are not part of the frame, they too are also not scrambled or descrambled or used for scrambling/descrambling. Accordingly, the state of the scrambler 400 at the end of the previous frame 200 is used as the initial condition at the beginning of the next frame 200. To accomplish this, the scrambler 400 stops scrambling or descrambling at the last byte 310 of a frame payload FCS 208 of a frame 200, and restarts scrambling or descrambling at the first byte of the Type Header 204 of the next frame 200. Known solutions use a brute-force approach consisting of a set of W+1 partial scramblers and a controller to accomplish this.
FIG. 5 shows a brute-force scrambler/descrambler (scrambler) 500 as known in the art. The scrambler 500 uses W+1 partial scramblers/descramblers 502. The partial scramblers/descramblers 502 are similar to the scrambler 400 of FIG. 4. A total of W−1 of the partial scramblers/descramblers 502 accommodate the W−1 possible byte positions of the last byte 310 in the receive packet bus 300. Each partial descrambler is configured to handle a unique last byte 310 location from position 1 of the bus word 302 to position W of the bus word 302. An additional 2 partial scramblers/descramblers 502 are used for the cases where the bus word 302 contains the Core Header 202, and where the bus word is filled entirely with the payload 206. A 43-bit scrambler state 506 with memory, and a W+1 to 1 MUX 504 select which of the W+1 partial scramblers/descramblers 502 are used for each bit of an incoming data stream. The memory of the 43-bit scrambler state 506 can be a series of 43 delay modules. The use of 32+1 partial scramblers/descramblers 502 is trivial in a W=32 byte wide packet bus. A packet bus of W=512 bytes, however, would require 512+1 partial scramblers/descramblers 502.
It is, therefore, desirable to have a scrambler/descrambler which does not require W+1 partial scramblers/descramblers.